FIG. 1 illustrates an interactive help utility called a wizard 100, which appears as a modal window, within an application. The wizard generates windows that guide a user through each step of a particular task, such as starting up a word processing document in the correct format for a business letter. The GUI window of the wizard 100, like other window applications, includes a title bar 102, which is a horizontal space at the top of a window that contains the name of the window. Appearing as a square button in the right comer of the title bar 102 with an X mark on it is a close button 104. Clicking on the close button 104 cancels the wizard 100. The wizard 100 also includes a number of sequential screens 106, 108, and 110 that present information and receive input (information) from a user during the performance of the task defined by the wizard. The screens 106-110 may be navigated back and forth using a back button 112 or a next button 114. After collecting sufficient information from a user, the wizard 100 presents a finish button 115. A user clicking the finish button causes the wizard 100 to proceed to perform the wizard's task. At any point, a user may exit from the wizard 100 by clicking on a cancel button 116. Clicking on the cancel button causes the wizard 100 to quit and returns the user to the application that originally invoked the wizard 100.
Wizards and similar programs typically present a set of choices from which a user selects to accomplish a particular task. This works fine as long as the choices are static, but can become unfeasible when the choices are dependent on a number of factors, such as a user's country, language, and locale. For example, suppose a software manufacturer designs a wizard to help a user print electronic photographic images by presenting a list of service providers available to a user via a wide area network such as the Internet (hereafter Web Server providers) so that the user, who may be located in Seattle, Washington, for example, may choose to obtain high quality prints from his images. Between the time that a software manufacturer produces a wizard with a fixed list of Web service providers and the time that a user uses the wizard to help him obtain prints, one or more of the Web service providers in the list may no longer be in business. Thus, the information that is contained in a wizard may become irrelevant. When a user selects a Web service provider that no longer exists, the user's computing experience is frustrated and he may no longer trust information that is presented to him.
Another problem is the expense that a software manufacturer has to commit to localize a wizard to make it appropriate for the country, language, and locale of a user. In other words, a wizard that presents a list of Web service providers who can communicate in English is helpful to a user who is in Seattle, Wash., but is rather unhelpful to a non-English communicating user who is located in China or Saudi Arabia. Even if a software manufacturer has a sufficient engineering budget to localize a wizard to any country in which the wizard may be used, certain Web service providers, while active and available for business in one country, may be unavailable or unlicensed to operate in another country.
A partial solution is provided by a system 200, as shown in FIG. 2, that breaks a wizard into components so that when a wizard's functionality requires augmentation or updating, it can be easily changed. The system 200 includes multiple servers 208-212, that contribute one or more wizard components or wizard pages 106-110 to create a wizard. The assembly process to produce a wizard, in accordance with the system 200, is driven and controlled from a script file 202. Each wizard component 208-212 can be written in any language. The assembly process of a wizard begins when the script file 202 is loaded into a wizard engine 206. The wizard engine 206 parses the script file 202 to find the location(s) of the wizard components, which are located on servers 208-212. The wizard engine 206 is executed on a computer 204. Whereas changes made to the wizard 100 require re-design, re-compilation, and re-testing of the wizard 100, only those components that are affected by changes need to be re-designed in a wizard assembled by the system 200. Thus, if a Web service provider is no longer a going concern, a component that displays a list of Web service providers can be changed in the system 200 while other components remain the same. However, because of the amount of time required to re-design, re-compile, and re-test the affected components, an assembled wizard by the system 200 may not necessarily reflect further changes in the availability of Web service providers.
Instead of using the script file 202 to assemble a wizard from multiple components, another way to create a wizard is to use a markup language, such as extensible markup language (XML), without writing, compiling, and debugging code, as illustrated by a system 300 shown in FIG. 3. An XML file 302 contains customized tags that allow non-programmers to create portions of a wizard such as: the title bar 102; the close button 104; the screen 106; the back button 112; the next button 114; and the cancel button 116. An interpreter 304 receives and parses the XML file 302 to immediately render a wizard in accordance with the customized tags contained in the XML file 302. While a significant advance over compiled wizards, the system 300 provides no facility to create a wizard that is suitable to a user's country, language, locale.
Thus, there is a need for a method and a system for exchanging dynamic information, which is formed from a customizable, tag-based language, that can describe and contain data to facilitate creating, updating, or interpreting the data such that the presented Web service providers are suitable to a user's country, language, and locale, while avoiding the foregoing and other problems associated with existing wizards and similar programs.